The Open Mobile Alliance (OMA) has developed a number of protocols for device management in a network, including the OMA Device Management (DM) protocol, the OMA Gateway Managed Object (GwMO) protocol, and the OMA Lightweight Machine-to-Machine (LWM2M) protocol. The OMA DM protocol may be used to manage standalone devices, such as mobile devices, in a network. The OMA GwMO protocol may be used for managing end devices behind a gateway, and the OMA LWM2M may be used for managing constrained machine-to-machine (M2M) or Internet-of-Things (IoT) devices.
The general architecture of the OMA DM protocol is shown in FIG. 1. A DM Server 102 (sometimes also referred to as a Management Server) is the master entity that sends commands to DM Clients running on devices or gateways (such as device or gateway 104) to manage them. The DM Client is an entity that runs on devices or gateways to provide communications with the DM Server 102. It is also referred to as a Management Client. A DM Session is an OMA DM protocol management session created between a DM Server and a DM Client. DM commands are sent within this session between the two entities.
The commands operate on nodes that are logically grouped together into Managed Objects (MOs) on the devices. An MO is a collection of DM nodes that collectively provide some management operation such as software download (SCOMO) or device information (DevInfo MO). The MOs are organized into a hierarchical tree structure called the DM Tree or Management Tree, shown at 106 in FIG. 1. An example DM Tree is illustrated in FIG. 2.
A DM node is a single element within a Managed Object or DM Tree. It can be an interior node or a leaf node. Interior nodes have child nodes; leaf nodes do not have child nodes and will contain some value or can be operated on by Execute commands.
In the OMA DM protocol, each MO is described by the OMA Device Description Framework (DDF). This DDF is an Extensible Markup Language (XML) document that is read by the DM Server to fully describe all the nodes contained within the Managed Object, and it describes what actions can be performed on each node. Elements found in the DDF are the node names, node properties, and values associated with the leaf nodes. The node properties include Description Framework Properties (DFProperties). These DFProperties contain meta-data about each node. DFProperties are properties defined during the specification of the MO and examples include AccessType, DefaultValue, Description, DFFormat, Occurrence, Scope, DFTitle, DFType, and CaseSense. In addition, Run Time Properties (RTProperties) are generated at run time and include properties such as Access Control List (ACL), Format, Name, Size, Title, Timestamp, Type, and Version Number.
FIG. 3 shows a simple example of a DDF document. Note that the details of the DFProperties have been purposely left out for brevity. In this example, the DDF describes an interior node with a URI “Vendor/ISP/GWInfo” and has a child node named “GWName”, which contains the value “gw.yyy.se”. “Vendor”, “ISP”, and “GWInfo” are names of interior nodes while “GWName” is the name of a leaf node. The DDF files show the format of the management object and the possible values that each node can take. The client and/or server are responsible for assigning values to each node. The DDF files are provisioned to the DM Server and DM Client to enable end to end support of the corresponding MO. Typically, this is done out of band from the normal operations of the DM Protocol.
FIG. 4 illustrates the architecture of the GwMO protocol. The GwMO protocol defines an intermediate OMA DM Gateway 402 that helps expand device management functionalities to end devices that are not directly reachable by a DM Server 406. End devices, such as end devices 404a, 404b, and 404c, communicate to the OMA DM Gateway 402, which then alerts the DM Server 406 of the new end devices. Device management commands are sent from the DM Server 406 to the OMA DM Gateway 402, which then distributes the commands to the end devices according to one of several different modes of operation. Three modes are defined: Transparent, Proxy, and Adaptation modes. In both Transparent and Proxy modes, the end devices understand native OMA DM commands while Adaptation mode requires translation from OMA DM Protocol to a non-OMA DM protocol.
Central to the operation of the OMA DM Gateway 402 is a GwMO Component (not shown). This entity provides five MOs to manage end devices behind a gateway: Device Inventory, Gateway Config, Fanout, Image Inventory, and End Device Trigger. The functionality of these MOs reuses the same message formats as the OMA DM Protocol, so it is designed to function seamlessly with an OMA DM system. The definition of the GwMO component allows OMA to extend its reach to support non-OMA DM devices, some of which may be more constrained than existing OMA DM devices.
The LWM2M protocol was developed to address the growing popularity of M2M communication networks as a means for managing M2M devices in such networks. LWM2M is based on the same client-server architecture as OMA DM, but uses a different communication protocol with a simpler and flatter resource tree that is more applicable to constrained devices, such as those found in M2M communication networks. In particular, LWM2M uses the Constrained Application Protocol (CoAP) and its resource tree is defined as Objects with underlying resources organized in a flat structure with fewer levels of hierarchies. The definition of Objects and resources in LWM2M is analogous to that of MOs and nodes in the OMA DM Protocol. FIG. 5 illustrates the LWM2M architecture. As shown, an LWM2M Server 502 is the master entity in the OMA LWM2M protocol. It communicates to LWM2M Clients (e.g., LWM2M Client 504) to provide device management and information reporting capabilities. LWM2M Clients run on constrained devices, such as M2M Device 506 within M2M or IoT systems that provide device management and information reporting capabilities to LWM2M Servers.
In addition to supporting device management, the LWM2M Protocol also supports service enablement provided by the constrained devices. Since a constrained device mostly provides data measurements for its particular application, information reporting is one of the main service enablements specified in the protocol. As such, the design of the Objects focuses on providing resources that will support device management and information reporting.